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BROADCAST MEDIA METADATA STRUCTURE 



FIELD OF THE INVENTION 

This invention relates, to methods and systems for storing 
and exchanging metadata, or data about data, between 
systems. It is particularly, but not exclusively, concerned 
with the storage and exchange of metadata associated with 
media materials, concepts and services within the context of 
media production and distribution, and its future evolution. 



BACKGROUND TO THE INVENTION 
10 The changes brought about in the broadcasting industry by 

the move to digital technology in all aspects of media 
production and distribution has exposed significant short- 
comings in traditional and existing methods and systems. 



The proliferation of distribution channels, using both push 
15 and pull technologies, has led to an increased demand for 

media content which cannot be serviced economically through 

original production alone but relies heavily on re-use. 

Information is the key to un-locking the re-use value of 

material, yet the industry has no agreed approach to 
20 generating and structuring this crucial data, or metadata, 

to enable efficient exchange of material between process 

stages or business parties. 

The move away from analogue or physical media capture and 
storage formats towards digital video, audio, text, stills, 

25 graphics and software has created new problems in terms of 

identifying and managing materials and tracking copyright 
intellectual properties across multiple incompatible and 
non-interoperating formats and systems. A video tape, in a 
box with a label, is a physical object which is managed 

30 through well-understood logistical methods. When the video 

information is transferred as digits into an Information 
Technology repository such as a server, it cannot be 
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distinguished from any other data, whether media or business 
data . 



Such data is not self -identifying ; it requires additional 
metadata to give it meaning, context and value, and that 
5 information must be available at any stage during the media 

production and distribution lifecycle . The lack of common 
description and management protocols in computer-based 
systems and among users in the Media domain has already led 
to loss of material, errors in retrieval and distribution, 
10 and accidental copyright infringement. 



The emerging capability of digital media formats to support 
embedded metadata offers an opportunity to attach business 
information to the audio or video for example, but if there 
are no standards for generation and exchange of metadata, 

15 serious inefficiencies will proliferate and solutions will 

be hard to find. In addition, early industry thinking about 
metadata development reflected a view that all metadata 
might have to be encoded on every section of media however 
small, such as a video frame or equivalent increment. Thus 

20 the business and technical metadata volumes could easily 

dwarf the media item, making huge demands on storage and 
slowing down access time, making metadata systems unviable. 

At a time when information accuracy and accessibility, and 
business agility are increasingly vital for the media 

25 industry, the new converging technologies are causing 
fragmentation, data loss, and over-loading on labour- 
intensive human ^''fixes''. This chaos is exacerbated by the 
proprietary approaches taken by individual equipment 
vendors, all with different systems supporting only partial 

30 solutions. 



Although there are some industrial initiatives underway to 
stimulate a more open approach, what has been lacking to 
date has been an overall understanding of the requirements. 
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The starting point must be an architectural framework which 
defines the way in which all the information needed to 
support media" production and distribution in the digital 
domain (while not excluding analogue technology) can be 
5 effectively structured and exchanges between process stages 

and business parties, and linked the with media to which it 
relates. Inter-operable systems can then be built to support 
that architecture, and metadata can be managed efficiently 
in terms of storage and transfer. 

10 SUMMARY OF THE INVENTION 

The invention, therefore, aims to provide such an 
architecture. According to the invention there is provided 
a method for defining a metadata structure relating to media 
materials, concepts and services, the method comprising the 

15 steps of: defining a plurality of storage entities at a 

plurality of levels for metadata relating to media 
materials, concepts and services, the storage entities 
having a plurality of storage elements and being related 
with a media metadata subject grouping, and arranged in 

20 hierarchical and non-hierarchical relationships allowing an 

appropriate combination of elements as required; storing 
metadata relating to a given storage entity in one of a 
plurality of storage elements of the entity at that level, 
each storage element representing an attribute or 

25 characteristic of the entity subject or media material; 

arranging media metadata entities and attributes relating 
directly to the media material, concepts and services in 
hierarchical and non-hierarchical entity level relationships 
allowing an appropriate combination of elements are 

30 required; and wherein for hierarchical entities, the storage 

elements of storage entities at a level apart from the 
lowest level, comprise the storage elements of the 
immediately lower storage level. 

The invention further provides a data structure for defining 
35 broadcast media metadata comprising: a plurality of storage 
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entities for metadata relating to media materials, concepts 
and services, the entities being arranged in storage levels 
and each entity comprising a plurality of storage elements 
each for storing metadata relating to a given entity, each 
5 storage element representing an attribute or characteristic 

of the entity subject or the media material; wherein the 
storage levels are hierarchical and non-hierarchical 
allowing the appropriate combination of elements as 
required, where the levels are hierarchical, the storage 
10 elements of storage entities, apart from the lowest level, 

comprise the stores of the immediately lower storage level. 

The invention still further provides a data structure for 
defining media metadata comprising: a plurality of storage 
entities for metadata relating to media production and 

15 distribution, the entities being arranged at storage levels 

and each entity comprising a plurality of storage elements 
each holding metadata relating to a given entity level, each 
storage element representing an attribute or characteristic 
of the entity subject or the media material; a plurality of 

20 levels of business entities each comprising storage elements 

storing business metadata, the business entities being 
linked to the metadata stores at a storage level dependent 
on the business element metadata, one of the plurality of 
levels of business stores comprising a rights level and 

25 having one or more storage entities containing business 

metadata identifying legal rights attached to the media 
material, the business metadata including the legal 
jurisdiction of the right, the geographical territory of the 
right, the duration of the right and the owner of the right; 

30 wherein the metadata storage levels are hierarchical and 
non-hierarchical and, for hierarchical storage levels, the 
metadata stored in the storage elements of storage entities 
at a level, apart from the lowest level comprise the stores 
of the immediately lower storage level. 
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The invention also provides a data structure for defining 
media metadata comprising: a plurality of storage entities 
for metadata relating to media production and distribution, 
the entities being arranged at storage levels and each 
entity comprising a plurality of storage elements each 
holding metadata relating to a given entity level, each 
storage element representing an attribute or characteristic 
of the entity subject or the media material; a rights store 
linked to at least one of the metadata stores and comprising 
one or more storage entities containing business metadata 
identifying legal rights attached to the media material, the 
business metadata including the legal jurisdiction of the 
right, the geographical territory of the right, the duration 
of the right and the owner of the right; wherein the 
metadata storage levels are hierarchical and non- 
hierarchical and, for hierarchical storage levels, the 
metadata stored in the storage elements of storage entities 
at a level, apart from the lowest level, comprise the stores 
of the immediately lower storage level. 

A method embodying the invention may define a metadata 
structure relating to media material, concepts and services, 
which in turn provides a method for defining storage and 
exchange requirements. 

The method comprises of the steps of defining a plurality of 
storage entities for metadata related to media production 
and distribution, the entities being associated with a media 
metadata subject grouping, and arranged in hierarchical and 
non-hierarchical relationships. Metadata relating to a given 
storage entity is organised in one of a plurality of storage 
elements at that level, each element representing an 
attribute or characteristic of the entity subject or media 
material . 

Media metadata entities and attributes relating directly to 
media material, concepts and services are arranged 
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hierarchically and non-hierarchically allowing the 
appropriate combinations of metadata to be supported. Where 
storage levels are hierarchical, the storage elements in 
stores at the lower levels are linked in defined 
5 relationships with stores at the higher levels. The result 
is a structure for defining metadata, wherein all individual 
metadata values may be organised according to the entities 
and relationships defined. 

A data structure embodying the invention may define the 
business data not directly related to media material but 
vital for its management and exploitation, by defining a 
plurality of business entities each comprising business 
elements storing business data, the business stores being 
related to the media metadata stores at a level dependent on 
the business element metadata. One or more of a plurality of 
entities comprises a rights storage entity or entities 
containing business metadata identifying legal rights 
attached to the media material, wherein the relationships 
with the appropriate media metadata are recorded. Where 
storage levels are hierarchical, the storage elements in 
stores at the lower levels are linked in defined 
relationships with stores at the higher levels. 

The invention also provides a method of defining a standard 
media exchange framework comprising the steps of: storing 
25 media metadata by the method defined above; defining 

industry-specific processes involved in media production and 
distribution, and defining the flow of data between them. 
The metadata defined by the metadata structure may be mapped 
on to this process flow, in order to define metadata 
30 exchange requirements between different process stages and 

business areas. 

A method embodying the invention may define media metadata 
and related business metadata exchange requirements by using 
the process flow definitions on to which the storage 
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entities may be mapped, so that the systems requirements at 
each interface may be identified against a standard 
structure, providing a framework for systems development and 
integration. In providing the hierarchical and non- 
5 hierarchical structure of storage entities and attributes, 

the method and data structure serves as a basis for defining 
standard media metadata exchange requirements between 
process and business interfaces at an appropriate level of 
granularity . 

10 Embodiments of the invention have the advantage that 

metadata related to a media item can be stored in a manner 
which minimises storage space and minimises retrieval time. 
A metadata item for a media item need only be stored once 
and is retrievable at any point in the broadcast media 

15 chain. Furthermore, embodiments of the invention allow 

media exchange formats to be defined which embed certain 
metadata in the media object, for example into a video frame 
from where they can be accessed at any point in the 
broadcast chain. 

20 The term media concept referred to herein refers to an idea 

for a media item such as a television programme or series of 
programmes independent of its realisation. It is common in 
the media industry to buy, sell and licence media concepts 
and as such they may be regarded as intellectual property. 

25 BRIEF DESCRIPTION OF DRAWINGS 

Embodiments of the invention will now be described by way of 
example, and with reference to the accompanying drawings, in 
whi ch : 

Figure la) , l b) and Ic^ show three views of an Entity 
30 Relationship Diagram embodying the inventions- 

Figure 2 is an overall process flow diagram illustrating 
broadcast media production and distribution; 
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Figure 3 shows in more detail the CREATE TV/RADIO PROGRAMME 
process box of figure 2; 

Figure 4 shows in more detail the GATHER NEWS process box of 
figure 2 T 

5 Figure 5 shows the RESEARCH EVENT process of figure 4 in 

more def^il; 

Figure 6 shows ALLOCATE RESOURCES process of figure 4 in 
more details- 
Figure 7 shows the CREATE NEWS PROGRAMMES process of figure 
10 2 in more detail; 

Figure 8 shows the SELECT PROGRAMME CONTENT process of 
figure 7 in more detail; 

Figure 9 shows the RESEARCH AND CAPTURE process of figure 7 
in mor"e"^etail ; 

15 Figure 10 shows the COMMISSION OUTPUT process in more 

detail; " 

Figure 11 shows the EVALUATE and SELECT OFFERS process in 
figure 10 in more detail; 

Figure 12 shows the DEVISE OUTLINE SCHEDULE process of 
20 figure 10 in more detail; 

Figure 13 shows the ACQUIRE PROGRAMME /EVENT RIGHT process of 
figure 2 in more detail; 

Figure 14 shows the SCHEDULE & PROMOTE process of figure 2 
in more detail; 
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Figure 15 shows the CREATE TRANSMISSION SCHEDULE process of 
figure 14 in more detail; 

Figure 16 shows the PLAN & INITIATE ON-AIR PUBLICITY process 
of figure^4 in more detail; 

5 Figure 17 shows the PLAY-OUT AND TRANSMIT process of figure 

2 in more^detail; 

Figure 18 shows the PERFORM PLAY-OUT process of figure 17 in 
more det^oTi; 

Figure 19 shows the MANAGE MATERIAL STORE and ARCHIVE 
10 process oT" figure 2 in more detail; 

Figure 20 shows the MANAGE INCOMING MATERIAL process of 
figure 19 in more detail; 

Figure 21 shows the RETRIEVE MATERIAL process of figure 19 
in more^'^'ctetail; 

15 Figure 22 shows the MANAGE RIGHTS AGENCY process of figure 

2 in more detail; 

Figure 2 3 shows the PLAN OUTPUT process of figure 2 in more 
detail;^^ ^ 

Figure 24 shows the UNDERSTAND AUDIENCE & COMPETITORS 
20 process of figure 2 in more detail; 

Figure 25 shows the MANAGE RESEARCH STATISTICS process of 

figure 24 in more detail; 

Figure 26 shows the HANDLE AUDIENCE FEEDBACK process of 

figure 24 in more detail; 
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Figure 2 1 s hows the DEAL WITH AUDIENCE FEEDBACK process of 
figure 24 in more detail; and 

Figure 2 8 shows the PROVIDE RESOURCES TO PROGRAMMES process 
of figu?^2 in more detail. 

5 DESCRIPTION OF BEST MODE 

In the entity relationship diagram of figures la) to Ic) , it 
is shown how a media material item such as a television 
programme may be described as an interrelated series of 
entities. The term media material includes any logical whole 

10 piece of media for distribution. It may, for example, be a 

news item, a section of video, a series of data or software 
or audio. In figure la), the central entity is the EDITORIAL 
OBJECT VERSION 10 together with its sub-types PROGRAMME 
VERSION 11 and ITEM VERSION 12 (it is assumed that these are 

15 included whenever the main entity 10 is referred to) . An 

entity is a logical grouping of data to be stored, retrieved 
and used. This data is all programme and item metadata as it 
describes a characteristic or attribute of the PROGRAMME or 
EDITORIAL OBJECT VERSION. The entity contains a number of 

20 data items. Thus, the EDITORIAL OBJECT VERSION entity 10 

holds both key and non-key data. The key data for the 
EDITORIAL OBJECT VERSION entity is the EOV count PKl and EOC 
number PK2 which together make up a unique identifier. The 
tags PKl and PK2 show the two parts of the primary key. For 

25 data to be allocated a primary key it should be unique in 

its own right or unique when taken with another data item. 
The primary key is the "way-in" to the information contained 
within the entity. It can be seen from figure la) that all 
the entities contain key data. Key data is essential to 

30 those entities. An entity might only hold key data. 

The EDITORIAL OBJECT CONCEPT entity 20 is an example of an 
entity which holds key metadata which is unique in its own 
right. Thus, the primary key is simply EOC number PKl. 
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In EDITORIAL OBJECT VERSION entity 10, the non-key data 
relates to editorial information about the programme or 
item, such as the title, working title, synopsis, etc. 
Technical information about an EDITORIAL_OB JECT_VERSION is 
found through other entities such as EDITORIAL_OBJECT 
VERSION_INST 30 and MEDIA_OB JECT_INSTANCE 32. The term 
instance refers to a unique material embodiment of an 
editorial or media object, whether electronic or physical 
(eg film), signal stream or file. Different instances can 
exist of the same object, with different technical 
attributes . 

THE EDITORIAL OBJECT VERSION entity 10 is linked to a number 
of other entities. As the programme or item is the end 
product of the creation process, it follows that the vast 
majority of the other entities will, either directly or 
indirectly, be linked to the EDITORIAL OBJECT VERSION 10. 

The link between entities is a relationship, with the link 
line showing how the data is related. At the end of the 
relationship line are two symbols indicating whether the 
connection is mandatory and whether only one or many 
connecting entities are to be supported. A particular 
relationship with only a single symbol indicates an entity 
being a subtype of another entity. 

In the example of figure la) , the EDITORIAL OBJECT VERSION 
entity 10 is linked to a number of other entities such as 
the entity EDITORIAL OBJECT CONCEPT 20, the relationship 
being that the EDITORIAL OBJECT CONCEPT may give rise to a 
number of EDITORIAL OBJECT VERSIONS. The EDITORIAL OBJECT 
VERSION PROGRAMME is linked to the entity SOUND, FORMAT, 
TYPE, 27, the relationship being "may describe". The 
EDITORIAL OBJECT VERSION entity 10 is linked to the 
EDITORIAL OBJECT VERSION INST entity 30 by the relationship 
"may be instantiated as". A wide variety of terms may be 
used to describe relationships between entities and the 
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terms vary from the very specific, such as "is made up of" 
to the more vague, such as ^'has associated". 

Many of the entities having relationships with the EDITORIAL 
OBJECT VERSION 10 in turn have relationships with other 
5 entities some of which have relationships with the EDITORIAL 

OBJECT VERSION entity 10. Thus, the EDITORIAL OBJECT CONCEPT 
entity 20 has the relationship "may be specified in" with 
the OFFER LINK EOC entity which in turn has the relationship 
"may specify" with the OFFER entity 28 which has the 
10 relationship "may specify as examples" with the 

OFFER_LINK_EOV_EXAMPLE entity 67. That latter entity has the 
relationship "may be specified as examples in" with the 
EDITORIAL OBJECT VERSION entity 10. 

The entity relationship diagrams of figures la)-lc) provide 
15 a hierarchical and non-hierarchical breakdown of programme 

content and metadata through media object instances which 
point to individual media objects. The structure also allows 
optimal storage of information by linking information to 
objects at the logical level. Thus, rights, incorporating 
20 contributor rights and/or exploitation rights are linked to 

programmes and at lower levels, through a contract for a 
particular role, such as rights owner. Thus it can be seen 
that not all programme metadata need be stored at a very low 
level, such as on a video frame, as has previously been 
25 proposed. The model sets out the entities required to hold 

metadata for say, a programme at the optimal level, not, for 
example, duplicating it across low level details such as 
video frames. 

30 Figures la) to Ic) set out the range of metadata 

hierarchical relationships necessary to support appropriate 
media metadata structures. 

The EDIT0RIAL_0BJECT_VERSION entity 10 may be instantiated 
in terms of a number of media object instances which 
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represent the physical make up of the item. These are 
represented by the MEDIA_OB JECT_INSTANCE entity 32. The 
media object instance is connected to only one of a number 
of different elements such as shots, audio clip, text, 
graphics and stills which are determined through the 
relationship to the entity MEDIA_OBJECT_CONTENT entity 31 to 
MEDIA OBJECT entity 14 and its associated sub-types. Thus a 
given media object instance only comprises shots, or stills, 
etc. Each of these are represented by their own entity. 
Stored at each level is metadata relating to the media item 
at that level. These storage elements can then be combined 
upwards in a hierarchical and non-hierarchical structure 
with the data stored at each level being appropriate to that 
level. Thus, a given piece of metadata only needs to be 
stored once throughout the whole broadcast chain from 
commissioning of a programme to transmission and 
exploitation . 

In the digital environment, business and technical data 
become indistinguishable. It is an advantage of the 
embodiment that business information can be linked to the 
appropriate level entity. This again reduces the amount of 
storage required and avoids the need for business 
information to be embedded in the individual video or audio 
frames. One example of this is the STORY entity 25 which is 
linked to the MEDIA OBJECT and EDITORIAL OBJECT entities 14, 
10 via link entities. If the previously assumed constraints 
were followed, this data would have been embedded at the 
frame level. 

The manner in which the model handles rights is itself 
novel. As can be seen from figure Ic, the RIGHT entity 61 
has RIG number and COM number as key data, and 
jurisdiction, start date, end date, and condition as non-key 
data. The condition data item is included to provide a 
field for storage of additional information required to 
define the right over and above the jurisdiction, and other 
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provided for. The RIGHT entity 61 is linked to the TERRITORY 
entity 63 through the RIGHT LINK TERRITORY entity 72 along 
the relationship "is valid in". This allows a series of pre- 
defined territories for rights management to be specified. 

Within an organisation's development local equivalent names 
would be defined as synonyms for the terms used here, 
different parts of the broadcasting industry may use 
different terminology. The data dictionary is therefore a 
compendium of data items with their definitions 
(complemented with local synonyms) and provides a basis to 
all the items a broadcaster needs to know about a media item 
throughout its life cycle with flexibility to cope with 
specialised terminology and future developments. 

The structure of the data model described has hierarchical 
and non-hierarchical areas representing different levels of 
granularity through brand, programme group, programme, item 
and media objects. The entities are linked by relationships 
that support the expected connections across sets of 
metadata necessary to support business functionality. Each 
of the metadata items in figures la) to c) would appear in 
the data dictionary. Relationships linking data elements to 
the programme entity provide its CV or Resume. 

In figure la), the MEDIA OBJECT entity 14 is shown as having 
five different sub-types: SHOT entity 15, AUDIO CLIP entity 
16, TEXT entity 17, GRAPHIC entity 17 and STILL entity 19. 
Each of these sub-type entities contain metadata relating to 
the subtype- Thus, the AUDIO CLIP entity contains audio 
metadata, the GRAPHIC entity, graphic metadata etc. 

Each of the entities may be realised as a storage entity 
having a series of storage elements . 

Each of the entities may be realised as a storage entity 
having a series of storage elements. 
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KEY DATA 

MOB Identifier (PKl) 



15 - 

contained in the entity MEDIA 

NON-KEY DATA 

MOB Title 
MOB Creation Date 
MOB Creation Time 
MOB Description 
Format 

Original Format 



5 Examples of entries from the data dictionary for some of the 
entities shown in figures la), b) and c) are as follows: 

AUDIO CLIP (16) 

The entity represents an editorial description of a section 
of continuous/discrete sound from a defined viewpoint. The 
10 sound may be being planned to be captured, edited, or 

transmitted, 

BRAND (22) 

The name applied to a collection of assets which could 
include a series of programmes. The assets could cover 
15 programmes, books, videos, characters, magazines, toys etc. 

A brand can be defined at a high level as BBC Sport or as a 
sub-Brand as Grandstand. 

BRIEF (41) 

The document used by a Commissioning Editor to describe the 
20 programme or programmes required for publication. 
Also known as Commissioning Brief. 



GENRE (39) 




# 
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A domain-specific conceptual grouping of programmes, e.g. 
comedy, drama etc. It is because genres are domain specific 
that a single programme concept may be described in terms of 
multiple genres. 

PROGRAMME CIAS S I FI CATION (29) 

Used to describe the functional type of programme, for 
example ordinary scheduled programme, trail, time signal, 
outlet ident. 

PROGRAMME GROUP (21) 

A grouping of programmes with shared identification and 
branding linked by common character, subject matter, style 
or story. Could be a series, serial or themed grouping. A 
fiction series (drama or comedy) will have common 
characters, themes and/or style between episodes, but 
individual stories, A fictional series will have a common 
story running across all episodes, with part being told in 
each. A factual series may have either individual or shared 
stories/arguments, such as a history series. A series may be 
occasional or regular in its transmission pattern - a serial 
will always have a prescribed transmission pattern and 
order. A themed group may draw together programme versions 
based around a campaign or anniversary. 

PROGRAMME TYPE (24) 

Programme Type is the category of programme type taken from 
a standardised list for transmission to the consumer. 
Commonly used in RDS delivery, DAB delivery and iyiPEG-2 
delivery. Programme types include News, Sport, Traffic 
Information, Pop, Classical, with further sub- 
categorisation. Also used for EPGs . 

PUBLICATION EVENT (42) 

This is the window of availability for a consumer to view or 
listen to a version of a Programme. 
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RIGHT (61) 

An interest, or permission, which is recognised and 
protected by law. This entity records the detail of each 
right which has been acquired for exploitation purposes. 

5 SHOT (15) 

The entity provides .the editorial description for a 
continuous section of moving images from a defined 
viewpoint, such as video or film. The section may be 
planned, captured, created from other recorded images or 
10 transmitted. 

STILL (19) 

An editorial description of an image with no duration , but 
persistence e.g. a photo, or single frame extracted from a 
shot. The description may apply to a still image that is 
15 planned to be taken, captured, edited or transmitted. 

SUBJECT REFERENCE (43) 

This reference applies to the subject of the material 
(compared with, for example, the contributors or the action 
20 location) and is a "tag" by which a user may retrieve the 

material. 

TEXT (17) 

The entity provides an editorial description for a media 
object that contains alphanumeric content to be included in 
25 a presentation e.g. captions, website text, teletext. 

To assist in understanding how the data model operates it is 
helpful to consider a media object such as footage of 
wildlife. At the MEDIA OBJECT entity level information 
about this footage is stored such as the identifier, its 
30 name, creation date etc as shown in figure 1(a), A simple 



wo 00/45294 PCT/GB99/03010 



- 18 - 

object represents a continuous stream of action. Media 
objects may only exist conceptually, that is they may not 
have been captured. When an object is captured the data held 
at the level of the MEDIA OBJECT entity is complemented by 
5 technical information about the digital representation of 
the action stored in the MEDIA OBJECT CONTENT and MEDIA 
OBJECT INSTANCE entities 31 and 32. The combination of 
simple objects to become footage, or to become a compound 
media object is represented in the MOI SEGMENT USAGE entity 
10 33, the complementary information about any processing 
applied being stored in the TRANSFORM and TRANSITION entity 
38. 

The audio clip used, for example in the signature tune for 
one of the programmes may have rights attached to it and may 
15 have been used for other programmes. 

Prior to the present invention it was an assumed constraint 
that all the data represented by the footage would either be 
to store all of it for each frame of each shot or for it to 
be largely lost or stored in many places simultaneously. 

20 The first of these results in vast storage requirements and 
the second also has large storage overheads as well as being 
undesirable. The data model represented by figures la) to 
c) requires each metadata item to be stored only once and 
the hierarchical and non-hierarchical relationships between 

25 the storage objects means that all the information can be 
retrieved as required. Thus at the programme level one can 
access all the shot information and at the shot level one 
can access all the programme information for which that shot 
has been used. Given the shot data, one can move up the 

30 hierarchy through the MEDIA OBJECT, CONTENT, MEDIA OBJECT 

INSTANCE, EDITORIAL OBJECT VERSION INST and PUBLICATION 
EVENT entities 31-32 to find out when and in what form the 
shot has been broadcast. 



wo 00/45294 PCT/GB99/03010 



- 19 - 

The data model gives a representation of the data required 
by media business processes. The actual processes can be 
represented by' process flow diagrams. Process flow diagrams 
consist of process, data flows, data stores, and external 
5 entities and illustrate the process involved in the 
broadcast media production chain. In a process box, the 
action is linked with nouns to describe the process. The 
diagram does not show how many times the process is executed 
or any conditions that may prevent the process from being 

10 executed. However, the process must be triggered by a data 

flow. A data flow carries data in a packet into and out of 
processes and must change the data in some way. The data on 
the data flow is broken down into data structures and data 
items/elements. Data may flow to and from an external entity 

15 which is a source or recipient of data. 

An external entity is a person, role organisation or body 
that is outside the area represented by the process flow 
diagram and not necessarily to the organisation as a whole. 
A data store is a repository (possible temporary) of data, 

20 Everything in it should be retrieved and used by a process 

somewhere and data stored must be placed there by a process. 
Figure 2 shows the content creation and distribution process 
flow diagram for a broadcasting organisation. Figures 3-28 
show process flow diagrams for each of the processes 

25 illustrated in figure 2. 

Thus the content creation and distribution process is broken 
down into twelve processes. Each of these processes are in 
turn broken down into a number of sub-processes. Central to 
this is CREATE TV/RADIO PROGRAMME 72 which has data flows 
30 from sources 74, 76 which represent an external archive and 

a contributor. The data flow from the archive 74 represents 
information and footage. Data flows both from and to the 
contributor, the flow into the contributor being contractual 
and the flow from the contributor being availability. There 
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is further flow of data to an external entity 77 
representing billing to broadcasting data services. 

The process 72 has a data flow between the process PROVIDE 
RESOURCES to PROGRAMMES 78, the flow from the CREATE 
TV/RADIO PROGRAMME process 72 representing bookings and 
demand forecast and the flow to the process representing 
resources, equipment, studios and quotes. 

The process CREATE TV/RADIO PROGRAMME 72 has data flow to 
the process COMMISSION OUTPUT 82 with data representing 
offers flowing from the CREATE TV/RADIO PROGRAMME 72 process 
to the commission output process and data representing 
commissioning brief, and offer response flowing to the 
CREATE TV/RADIO PROGRAMME process. Data included in 
production contract will flow both ways. The CREATE TV/RADIO 
PROGRAMME process 72 will exchange data with the PLAY-OUT 
and TRANSMIT process 84 with the flow of data to PLAY-OUT 
and TRANSMIT process 84 representing programme feed and the 
data flow to the CREATE TV/RADIO PROGRAMME 72 representing 
a confirmed transmission. The data will flow from the CREATE 
TV/RADIO PROGRAMME process 72 to the process SCHEDULE and 
PROMOTE 86. That flow represents promotional material and 
presentation details . 

Data is exchanged between the CREATE TV/RADIO PROGRAMME 72 
process and the MANAGE MATERIAL STORE & ARCHIVE process 90. 
The data flow from the CREATE TV/RADIO PROGRAMME process 
represents pre-recorded programme tape, enquiries, rushes 
and documents together with transmitted programmes. The flow 
from the archive process 90 represents information and 
footage. Finally, there is a flow of data from the process 
ACQUIRE PROGRAMME EVENT RIGHT 92 to the CREATE TV/RADIO 
PROGRAMME process which represents an insert of programme or 
broadcast right. 
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The CREATE TV/RADIO PROGRAMME process 72 is illustrated 
in more detail in figure 3. 

The CREATE TV/RADIO PROGRAMME process 72 may be broken down 
into 6 sub-processes as follows: RESEARCH AND SUBMIT OFFER 
5 196; PLAN PROGRAMME 198; PREPARE AND RESEARCH 200; CAPTURE 

MATERIAL 202; MANIPULATE MATERIAL 204; and DELIVER 
PROGRAMME , 

As can be seen from figure 3, these processes involve 
the flow of data to and from 3 stores: PROGRAMME CONTENT 
10 207; PROGRAMME INFORMATION 210; and PRODUCTION SCHEDULE 212. 

Figure 2 shows a STORE 100 which represents the programming 
schedule. Data flows from the SCHEDULE STORE 100 to the 
SCHEDULE & PROMOTE PROCESS 8 6 representing MASTER SCHEDULE 
data. MASTER SCHEDULE data also flows from the commission 
15 output process to the SCHEDULE STORE 100, Data also flows to 

the SCHEDULE STORE 100 from the SCHEDULE & PROMOTE process 
86 representing trail details and confirmed timings and from 
the play-out and transmit process 84 representing actual 
start and finish times. 

20 The PROVIDE RESOURCES TO PROGRAMMES process is shown in more 

detail in figure 28. The process is broken down into six 
sub-processes: PROVIDE QUOTES & TAKE BOOKINGS 212; SET UP, 
MONITOR AND MANAGE JOB 214; PROVIDE RESOURCES 216; MANAGE 
PROJECT FINANCES 218; ESTABLISH COST OF PRODUCTS AND 

25 SERVICES 22 0; and FORECAST DEMANDS OF PRODUCTS AND SERVICES 



These sub-processes draw information from and send data to 
three stores; SCHEDULE & COSTING INFORMATION 224, PROJECT 
PLAN AND DOCUMENTATION 226 and EXPERIENCE LIBRARY 22 6. 



222. 



30 News within the organisation is represented by 2 processes; 

CREATE NEWS PROGRAMMES 88 and GATHER NEWS 94. The GATHER 
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NEWS process receives data flow from 6 external data 
sources: NEWS EDITORS 96, REGIONAL NEWS 98, NEWSROOM 102, 
EXTERNAL NEWS PROVIDERS 104, THE PUBLIC/AGENCIES AND WIRES 
106 AND EXTERNAL ARCHIVES 108. The data flow from NEWS 
EDITORS 96 represents guidance, from REGIONAL NEWS 98 and 
the NEWSROOM represents prospects and also from the NEWSROOM 
availability, from the EXTERNAL NEWS PROVIDERS 104 
represents knowledge of competition, from PUBLIC/AGENCIES 
AND WIRE 106 represents prospects and diary events and from 
EXTERNAL ARCHIVE represents information and footage. Data 
flow is also received from the MANAGE MATERIAL STORE & 
ARCHIVE process 90 representing information and footage. 
Data flows from the GATHER NEWS process 94 is to the 
NEWSROOM 102 representing an assignment, to the EXTERNAL 
ARCHIVE 108 representing an enquiry, to the MANAGE MATERIAL 
STORE & ARCHIVE 90 also representing an enquiry and to the 
CREATE NEWS PROGRAMMES process 88 representing a potential 
news item and an event, outline or story. 

The GATHER NEWS process 94 is illustrated in more detail in 
figures 4-6 and comprises three sub-processes MAINTAIN DAILY 
PROSPECTS 110, ALLOCATE RESOURCES 112 and RESEARCH EVENT 
114. The RESEARCH EVENT and ALLOCATE RESOURCES processes are 
illustrated in detail in figures 5 & 6. 

The CREATE NEWS PROGRAMMES process 88, in addition to the 
data flows already described, exchanges data with the 
EXTERNAL ARCHIVE source 108 by way of enquiries to the 
archive and information and footage from the archive. Data 
flow to the MANAGE MATERIAL STORE & ARCHIVE process 90 
represents enquiries, rushes and documents, together with 
pre-recorded programme tape whereas data flow from the 
MANAGE MATERIAL STORE & ARCHIVE process 90 represents 
information and footage. Data flow to the SCHEDULE AND 
PROMOTE process 8 6 represents promotional material and 
presentation details and data flow to the PLAY-OUT and 
TRANSMIT process 8 4 represents programme feed. 
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The CREATE NEWS PROGRAMME process is illustrated in more 
detail in figures 7-9 and comprises 4 sub-processes: SELECT 
PROGRAMME CONTENT 116, RESEARCH & CAPTURE 118, COMPILE 
PROGRAMME 120 and EDIT 122. The SELECT PROGRAMME content 
process is shown in more detail in figure 8 and the RESEARCH 
AND CAPTURE process is shown in more detail in figure 10. 
The SELECT PROGRAMME CONTENT process is broken down into 
four sub-processes: FINALISE NEWS ITEMS 228, ALLOCATE ROUGH 
TIMINGS 230, ALLOCATE PRODUCTION TEi\M 232 and CREATE DRAFT 
TREATMENT 234. These processes draw a data from a PROSPECTS 
store 234. The ALLOCATE PRODUCTION TEAM process also draws 
on available production staff data from a PRODUCTION ROTA 
store 236. 

The COMMISSION OUTPUT process 82, as well as the data flows 
described with the CREATE TV/RADIO PROGRAMME process 72 
receives data from a STORE 124 which represents the 
controllers stock of untransmitted material. Data is also 
received from an external entity, representing offers from 
EXTERNAL PRODUCTION BODIES 12 6. Data flows from the 
COMMISSION OUTPUT process to the EXTERNAL PRODUCTION BODY 
126 in the form of commissioning briefs, offer responses and 
production contracts. A second external recipient of data is 
the CORPORATE CENTRE 128 which receives data relevant to 
actual versus planned quotas. The COMMISSION OUTPUT process 
82 also receives data flow from the SCHEDULE STORE 100 and 
from a process PLAN OUTPUT SERVICE 130. The data from the 
STORE represents available slots and the data from the plan 
output service represents strategic output plan. Data in the 
form of requirements is sent to the SCHEDULE STORE 100. Data 
flows from the COMMISSION OUTPUT process to an UNDERSTAND 
AUDIENCE & COMPETITORS process 132 in the form of 
information requirements and flows from the UNDERSTAND 
AUDIENCE & COMPETITORS to the COMMISSION OUTPUT process in 
the form of filtered statistics. 
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The COMMISSION OUTPUT process is shown in more detail in 
figures 10-12 and comprises four processes: DEVISE OUTLINE 
SCHEDULE 134, EVALUATE AND SELECT OFFICERS 136, NEGOTIATE 
AND AWARD COMMISSION 138 and CHECK WITH QUOTA TARGETS 140. 

The ACQUIRE/ PROGRAMME EVENT RIGHT 92 process involves data 
flow between an external source representing the EVENT RIGHT 
HOLDER 142 with the data representing negotiation and 
contract and also flow of data in from EXTERNAL EVENT 
ORGANISERS 144 representing possible events to cover. Data 
flows to an EXTERNAL SOURCE 14 6 representing other 
distributors. Data representing negotiation and contract 
flows both ways to and from that source and data to that 
source represents '"ancillary rights which could be sold" and 
from the source represents "potential acquisitions and 
programme and paperwork information''. 

The ACQUIRE PROGRAMME /EVENT RIGHT process 92 is illustrated 
in more detail in figure 13. The process 92 is broken down 
into five sub-processes: IDENTIFY ACQUISITIONS & EVENTS 238, 
NEGOTIATE & AGREE CONTRACT 240, SELL ANCILLARY RIGHTS 242, 
MAINTAIN ACQUIRED STOCK 2 44 AND ALLOCATE PROGRAMME TO SLOT 
24 6. The sub-processes make use of data in the CONTROLLERS 
STOCK STORE 124, the SCHEDULE STORE 100 and a RIGHTS STORE 
248 . 

The SCHEDULE AND PROMOTE process 86, in addition to the data 
flows already described, receives a flow of data from the 
UNDERSTAND AUDIENCE & COMPETITORS process representing 
upheld complaints regarding the content of a broadcast and 
sends data to the BROADCASTING DATA SERVICES SOURCE 77 
representing weekly schedules and data to a recipient 
representing press and public relations 148 regarding off- 
air publicity and promotions. Data flows from the SCHEDULE 
AND PROMOTE process also to the UNDERSTAND AUDIENCE & 
COMPETITORS process representing information requirements. 
Data also flows to the PLAY-OUT & TRANSMIT process 
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representing on-air publicity and promotions and schedule 
and continuity script. Data representing a tape list flows 
to the MANAGE MATERIAL STORE & ARCHIVE process 90. 

The SCHEDULE AND PROMOTE process is illustrated in more 
detail in figures 14-16. The SCHEDULE & PROMOTE process is 
broken down into three sub-processes: CREATE, TRANSMISSION 
SCHEDULE 250, PLAN & INITIATE ON-AIR PUBLICITY 252 AND PLAN 
& INITIATE OFF-AIR PUBLICITY 254, Each of these processes 
relies on data flow to and from the SCHEDULE STORE 100. The 
CREATE TRANSMISSION SCHEDULE process is shown in more detail 
in figure 16 and the PLAN & INITIATE ON-AIR PUBLICITY 
process is shown in more detail in figure 16. 

The PLAY-OUT AND TRANSMIT process 84, in addition to the 
data flows described already sends information requirements 
to the UNDERSTAND AUDIENCE & COMPETITORS process 132, 
transmitted programme data, transmission log and original 
documents to the MANAGE MATERIAL STORE & ARCHIVE process 90. 
Pre-recorded tape information is received from the MANAGE 
MATERIAL STORE & ARCHIVE process and completed contract 
information flows to a MANAGE RIGHTS AGENCY process 150. 
Distribution data flows to, and transmission service data 
flows from an External source /recipient labelled 
DISTRIBUTION SERVICE PROVIDER 152. 

The PLAY-OUT AND TRANSMIT process is illustrated in more 
detail in figures 17 & 18. The PLAY-OUT & TRANSMIT process 
comprises 4 sub-processes: PERFORM PLAY-OUT 256, CAPTURE 
ACTUAL TRANSMISSION DETAILS 258, INITIATE POST-TRANSMISSION 
RIGHTS PAYMENT 260 and PERFORM PROMOS ANALYSIS 262. These 
processes draw on data from the SCHEDULE 100 and from a 
store of research statistics 264. The PERFORM PLAY-OUT sub- 
process is shown in more detail in figure 18. 

The MANAGE MATERIAL STORE & ARCHIVE process 90, in addition 
to the data flows described already receives a data flow 
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from the UNDERSTAND AUDIENCE & COMPETITORS process 132 in 
the form of request for tapes and sends data to that process 
in the form of pre-recorded programme tapes. Data flow from 
two external sources, EXTERNAL ARCHIVE 154 and ARCHIVE 
5 STEERING GROUP 156 represent material and rights flowing 

from outside the Organisation and strategic direction 
respectively . 

The MANAGE MATERIAL STORE & ARCHIVE process is illustrated 
in more detail in figures 19-21. The MANAGE MATERIAL STORE 

10 & ARCHIVE process may be broken down into three sub- 

processes as shown in figure 19. These processes are CREATE 
ARCHIVING POLICY 266, MANAGE INCOMING MATERIAL 268 and 
RETRIEVE MATERIAL 270. The latter two sub-processes draw on 
data in a MATERIAL STORE & ARCHIVE 272. The MANAGE INCOMING 

15 MATERIAL sub-process is shown in more detail in figure 20 
and the RETRIEVE MATERIAL sub-process is shown in more 
detail in figure 21. 

The MANAGE RIGHTS AGENCY process 150 will receive data flow 
representing Union & Framework Agreements from a source 
20 representing Union & Industry Bodies 156 and data will flow 

to a recipient representing Worldwide product Licences 158. 
The MANAGE RIGHTS AGENCY process is illustrated in more 
detail in figure 22 . 

The PLAN OUTPUT service process 130 receives data flows from 
25 external sources representing the chief executive broadcast 
160, the Government 162 and any relevant legislation 
represented here by the Broadcasting Act 1990, 164. Data 
also flows from the UNDERSTAND AUDIENCE & COMPETITORS 
process in the form of filtered statistics. Data is output 
30 to the SCHEDULE 100 in the form of news slots, to the 

COMMISSION OUTPUT process 82 in the form of strategic output 
plans and to the CREATE NEWS PROGRAMMES process 8 8 in the 
form of guaranteed news output. The plan output service is 
illustrated in more detail in figure 23. 
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The UNDERSTAND AUDIENCE & COMPETITORS process gathers 
information from a variety of external sources such as the 
Government 162 in the form of broadcasting requirements, for 
example under a broadcasting charter, from broadcasting 
5 industry monitoring services in the form of viewer /listener 

statistics, quote requests and contracts and other research 
results, from viewers and listeners in the form of 
complaints and feedback. Information flows to external 
sources in the form of published statistics to an annual 

10 report, reports and statistics to a given channel 

controller, responses to viewers and listeners and requests 
to statistical gathering agencies. The UNDERSTAND AUDIENCE 
Sc COMPETITORS process is illustrated in more detail in 
figures 24-27. The UNDERSTAND AUDIENCE & COMPETITORS process 

15 can be broken down into two sub-processes: MANAGE RESEARCH 

STATISTICS 274 and HANDLE AUDIENCE FEEDBACK 276. These sub- 
processes are shown in more detail in figures 25 & 26 
respectively. Figure 26 shows that the HANDLE AUDIENCE 
FEEDBACK sub-process can be further sub-divided into two 

20 more sub-processes: DEAL WITH AUDIENCE FEEDBACK 278 and 

INVESTIGATE COMPLAINTS 280. The DEAL WITH AUDIENCE FEEDBACK 
sub-process is further illustrated in figure 27. 

A combination of the data model of figures la) to c) and the 
PROCESS flow diagram of figure 2 can be used to develop a 
25 standard media exchange framework. This sets out the 

metadata items which must be associated with media material, 
concepts or services at each level of the entity model and 
can be used to define the exchange at each process 
interface . 

30 

An example of a possible exchange framework interface is the 
data which is required to be created by or loaded into a 
capture device such as a camera. This requires 
standardisation amongst camera manufacturers. Some of that 
35 information might then be imported into the device from a 

data store before capture, to be embedded with a media 
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material as it is created, then it and new data subsequently 
exported into an information system for media management 
purposes, or for access by an editing system for onward 
processing. Rather than capture the data at the end of a 
5 process, data is captured as it happens and is perpetuated, 

The media exchange architecture described enables the 
linking of media materials together with their metadata in 
a way which enables extremely efficient development, re-use 
and re-purposing of media in an integrated but distributed 
10 device and database. 

Application of the data structure described enables systems 
to be built which will integrate converging requirements of 
broadcast and media business systems. Systems which are 
compliant with this structure will be easier to integrate as 

15 the data exchange standard will be consistent regardless of 

the internal storage schemes used. Systems which are 
compliant in their internal storage schemes will also be 
optimumly efficient in their use of storage. Specific 
examples of systems which can be made compliant include 

20 media commissioning and scheduling systems, systems to 
support content production process, broadcast play-out 
systems, Internet websites, customer feedback capture 
systems, content asset management systems, intellectual 
property right systems and archive systems. 

25^ The data structure is tyf^cally implemented in software, for 
example the data dictionary may be held in a software 
y repository. \ 



